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VAXcluster Types 

Lesson Introduction 

This module discusses VAXcluster configurations. The two major types of 
VAXcluster configurations are Heterogeneous and Homogeneous. 

A Heterogeneous VAXcluster is a collection of VAX systems that can share 
resources. "~ 

A Homogfineous VAXcluster is a collection of VAX systems that have identical 
operating environments. 

Lesson Objectives 

1. Describe the characteristics of a Homogeneous VAXcluster. 

2. Describe the characteristics of a Heterogeneous VAXcluster. 

3. Define partitioning and describe how to avoid it. 

4. Define Quorum. 

Lesson Outline 

I. VAXcluster Types 
EL. Configurations 
III. Quorum 
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VAXcluster Overview 

The operating environment of a VAXcluster can be three basic types: 

- Homogeneous 

- Heterogeneous 

- A mixture 
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The Homogeneous VAXcluster 

• Homogeneous VAXclusters have the following characteristics: 

- Shared SYSUAF.DAT provides identical accounts on all nodes. 

- Same logical names defined on all nodes. 

- Mass storage devices and queues are shared. 

- Users have the same data access from each processor (node). 

- Users can continue to work despite failure of a node. 

• Example: 

A university time-sharing system used for student and instructor 
programming. Users may login to any node and still access their data on a 
shared HSC50 disk. This configuration provides a highly available computer 
system; if a CPU is removed from service for maintenance, the users can 
switch to another. 
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The Heterogeneous VAXcluster 

• Heterogeneous VAXclusters have these characteristics: 

- Each VAX processor presents a different operating environment to users. 

- Each node is autonomous, although data can be shared between them (not 
totally secure). 

- Can service specialized needs while allowing for sharing of data. 

- Mass storage devices and queues may not be available from every node. 

• Example: 

A corporation's central computer system, where the accounting engineering, 
and manufacturing departments each have their own computer system, can 
access a shared database containing inventory information, product orders, 
and scheduling data. 
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Homogeneous and Heterogeneous Clusters Combined 

• A mixture of environments has these features: 

- Some resources (storage devices) are shared between all nodes while others 
are not. 

- Some nodes have identical environments while others have different 
environments. 

Example: 

A three-node cluster in which two nodes provide a homogeneous time-sharing 
environment and a third node performs batch processing. 
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VAXcluster Configurations 

• All clusters (whether homogeneous or heterogenous) share certain 
characteristics: 

- Each VAX has its own system root; that root could be on a local disk or a 
shared HSC disk. 

- Each node has a hardware node address set in the switches of the LINK 
board of the CI interface. 

- Each node has a software system ID set up under SYSGEN (or under 
SEJSHOforanHSC). 

- Each node has a node name set up under SYSGEN (or under SETSHO for 
an HSC). 

- Each node has a DECnet node number and name (VAX systems only) that 
match the system ID and node name. 

- Names of devices reflect physical access paths. 

- Names of dual- ported devices are based on allocation class numbers. 
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VAXcluster Configurations (Cont.) 

( t ) The cluster shown on the opposite page has the following characteristics: 

- Each VAX has its own system disk. 

- Both VAX systems share a dual- ported RM05. 

- Access to the RM05 is possible because of the CI Bus connecting the two 
nodes. 

-" Each node has its own node number, node name, and allocation class 
number. 
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VAXcluster Configurations (Cont.) 

• The cluster shown on the opposite page has the following characteristics: 

- Multiple systems are booted from one HSC disk. 

- Two disks are dual-ported between two HSCs. 

- One disk is available to the cluster through the MSCP server, and is dual- 
ported between VAX nodes. 

- All systems can access any disk via the HSC or the MSCP server. 

- Terminals connected to a terminal server located on the ETHERNET allow 
; users to switch between systems in case of a node failure. 
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The Quorum Scheme 

• The Connection Manager on each node of a cluster performs the following: 

- Determines what nodes are in the cluster. 

- Reconfigures the cluster as nodes join or leave it. 

- Provides coordination between nodes to ensure the integrity of shared 
resources. 

• Partitioning exists when nodes of a cluster divide into two or more groups, 
each unaware of the other's existence. This causes disk file corruption since 
there will not be coordination between all systems sharing the same 
resources. 

• The quorum feature prevents partitioning. 

• The quorum scheme: 

- Each VAX node contributes a fixed number of votes toward a quorum. 

- The Connection Manager dynamically computes CLUSTER VOTES as the 
sum of all the votes by all members. 

- Each VAX node specifies an initial quorum value. 

- As nodes join/leave the cluster, the connection manager dynamically 
computes the cluster quorum to be the largest of the following: 

a. The current cluster quorum value. 

b. The value for quorum specified by each node. 

c. The value calculated from the formula: 

(total votes + 2)/2 
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The Quorum Scheme (Cont.) 

• Partition Prevention: 
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- If more than half the nodes form a functioning cluster, then the remaining 
nodes can never become a separate cluster. 

- If the current cluster quorum drops below quorum value, the cluster ^ — ^/ j^^ 
members suspend all process activity (cluster hangs). iXA 

- Quorum value is never lowered by the Connection Manager; only the 
System Manager can do this undecSBSS&ffififo. \)A^S 
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The number of votes per node and quorum are determined by SYSGEN 
parameters VOTES and QUORUM. 
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Special Case for Quorum: Two- Node VAXcluster 

• The quorum scheme has a problem in a two-node cluster configuration: 

- The computation of quorum results in (2 + 2)/2 = 2. 

- This means both nodes must be present to function. 

- The solution is to obtain another voting member. 

• The quorum disk solution ~ A quorum disk may act as a virtual node in a 
cluster, adding votes to achieve quorum. 

• Conditions for using a quorum disk: 

- The name of the disk must be specified on all nodes and must be the same 
on all nodes. 

- The disk must be accessible by every node. 

- The disk must contain a valid format file named QUORUM.DAT in the 
Master File Directory. 

• The name of the quorum disk and the number of votes contributed toward 

quorum are specified by SYSGEN parameters DISK QUORUM and 

QDSVOTES. 

• Therefore, a system booting into a cluster has three choices: 

- Join an existing cluster. 

- Form a cluster where no cluster exists. 

- Hang until quorum is reached. 

• Note that computing quorum entails knowing how many members are in the 
cluster and how many votes each member contributes toward quorum. This is 
done by the Connection Manager. 



VAXcluster Types 1-16 




\Jt\X 



I vpTs=: 



\JM 



^j 










Adds Ivor/? 



ToTKu Veres OF THE 

SYSTEM 5 

Also &esr r ^ 

• K *<£«, bKk ^ ^ L 

vnweb Disk iwr rev toovLb* 



st/c Acs 



SYSTEM BOOTING WITH A CI PORT 



System Booting with a CI Port 
Lesson Introduction 

This module discusses the sequence of events while booting a VAX into a cluster and 
how it differs from booting outside of a cluster. 

The boot file CIBOO can be modified and the new file saved as the default boot file. 

Shutting the system down and system time are also discussed. 

Lesson Objectives 

1. List the sequence of events during a system boot. 

2. Describe the changes that must be made to the boot file in order for the system 
to boot from a specific system root on an HSC-based disk. 

3. Shut down one or more nodes in a cluster without hanging the remaining 
systems in the cluster. 

Lesson Outline 

I. Local Disk 

H. HSC Disk 

m. Shutdown 

IV. Time 
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Overview 

• There are two ways to boot VAX within cluster: 

- Boot from an HSC disk 

- Boot from a local disk 

• Both methods are discussed on the following pages. 
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Booting From a Local Disk 

• Before VMS is brought up, a linked chain of files are executed. Each link in 
the chain is described in the following sections. 

• CI Port initialization, when booting from a local disk, follows this sequence: 
VMB.EXE (primary bootstrap) O©^ » ^A-fCS w* <>' 

a. Loaded from console media. v NL < /^0/7^ b )^^ La£<>£ ^ 

b. SizesmsEfea and identifies adapters; if CI Port is found, it loads the CI 
microcode (CI780.BIN) from the console device into a nonpaged pool. 

c. Loads SYSJJOOT from the system disk using a skeleton driver. 
SYSBOOT 

a. Configures the processor by loading parameters unique to the 
processor. 

b. Divides system virtual address space into sections and defines the 
system page table. 

c. Loads and runs executive image SYS.EXE. 

SYS.EXE 

a. Includes SCS routines and CLUSTRLOA.EXE, which contains the 
^ ^ Connection Manager. 

SO* ( .#> c l / b. Transfers control to ENIT. 
pX c *\ INTT 

n y p w own VftK y^ V* 0flA>A/£^ 

a. Turns on memory management. 

b. Initializes nonpaged pool. 

c. Creates adapter control block for CI Port. 

d. Starts the scheduler. 



r 
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Booting From a Local Disk (Cont.) 

The scheduler schedules the swapper process, which then creates the SYSINT 
process. 

SYSINIT.EXE 

Prompts roR- Time 

a. The Connection Manager is initialized and attempts to join cluster. 
Pit. rt/0\) Ouoftoa* bi%K0„ 

b. The system disk is mounted. 

c. Page file, swap file, and dump file are opened. 

d. STARTUP.COM is invoked. 
STARTUP.COM 

a. Start ERRFMT, OPCOM, CLUSTER__SERVER, JOB__CONTROL. 

b. SYSGENrun. Cc/of\(jufl£. U*(ib\JArR.& 

c. SYSTARTUP.COM invoked. 
SYSTARTUP.COM is a site-specific startup file. 
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Booting From an HSC Disk 

• Before VMS is brought up, a linked chain of files are executed. Each link in 
the chain is described in the following sections. 

• CI Port initialization, when booting from an HSC disk, follows this sequence: 
VMB.EXE (primary bootstrap) 

a. Loaded from console media. 

b. Sizes af^s^ and identifies adapters; if the CI Port is found, it loads the 
CI microcode (CI780.BIN) from the console device into physical 
memory. 

c. VMB contains a skeleton CI device driver that is used to load 
SYSBOOT. It loads microcode into the CI Port, establishes a virtu al 
circuit to HSC. establishes a conne ction to the di sk server, and loads 
SYSBOOT from the d isk. r OlOuNE Qf^ rfSC 

SYSBOOT (secondary bootstrap) 

a. Configures processor by loading parameters unique to the processor. 

b. Loads port driver (PADRIVER) and disk class driver (DUDRIVER). 

c. Loads and runs executive image SYS.EXE. 
SYS.EXE 

a. Includes SCSLOA.EXE (SCS layer) and CLUSTRLOA.EXE 
(Connection Manager). 

b. Transfers control to INTT. 
INTT 

a. Turns on memory management. 

b. Initializes nonpaged pool. 

c. Creates adapter control block that describes the CI Port. 
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Booting From an HSC Disk (Conk) 

d. Initializes PADRIVER|CI Port driver) and fiUDRIVER (disk class Sflr ^»*>' b^^ f 

driver) for use. ^ — — — L ^r D#-oft b is ^ Po p - r c ''<? #>~~ 

T ffe^j coMc<s S^c/k c< , A / 

(£) Lock Manager is initialized. # C ^ /A) "V^A) teAc 

f. Starts the scheduler. 

The scheduler schedules swapper process, which then creates the SYSINIT 
process. 

SYSINTT.EXE 

a. The Connection Manager is initialized and attempts to join the cluster. 

b. The system disk is mounted. 

c. Page file, swap file, and dump file are opened. 

d. STARTUP.COM is invoked. 
STARTUP.COM 

a. Start ERRFMT, OPCOM, CLUSTER_SERVER, JOB_CONTROL. 
bo System logical names are created. 

c. SYSGENisrun. 

d. SYSTARTUP.COM is invoked. 
SYSTARTUP.COM is site-specific startup file. 

a. Starts batch and print queues. 

V}V' b. Creates site-specific logical names. 

c. Mounts volumes other than system disk. 

d. Starts DECnet. 
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Booting From an HSC Disk (Cont.) 



• If you are booting from a remote disk, the processor must be able to find that 
disk in order to load SYSBOOT. 



• The boot files on the console media are used to "point" the CPU to the 
appropriate disk. 

• ThemostimportantfileiscalledCIBOO.CMD. <£><?0 * 

,Cca\ - " ° 

(4ABefore running CIBOO.CMD, registers R2 and R3 must be filled with valuj 
NL^ that tell VMB.EXE where to find the system disk: 



; >»0 R2 0304 ;HSC #3 AND #4 (hex) 
7* >»D R3 1 ;disk #1 (hex) 
^>»§CIBOO.CMD 

w + CIBOO.CMD 



CI PORT BOOT COMMAND FILE - CIBOO.CMD 
BOOT FROM CI 

DESIRED STATION ADORESS OF REMOTE 
PORT IS SET IN REGISTER 2 AND THE 
DESIRED UNIT NUMBER IS SET IN REGISTER 
3 BEFORE EXECUTING THIS COMMAND FILE 




HALT 

UNJAM 

INIT 

0EP0SIT/I 11 20003800 

DEPOSIT RO 20 

DEPOSIT Rl E 

DEPOSIT R4 

DEPOSIT RS 4000 

DEPOSIT FP 

START 20003000 

WAIT DONE 

j 

EXAMINE SP 

L0A0 VMB. EXE/START; 8 

START 9 



HALT PROCESSOR 
UNJAM SB I 
INIT PROCESSOR 
SET UP SCB8 
CI PORT 0EVICE 
CI TR*E 

BOOT BLOCK LBN (UNUSED) 
SOFTWARE BOOT FLAGS 
SET NO MACHINE CHK EXPECT 
START ROM PROGRAM 
! WAIT FOR COMPLETION 

! SHOW A00R OF WORKING MEM+'X200 
! LOAD PRIMARY BOOTSTRAP 
! START IT 
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Booting From an HSC Disk (Cont.) 

• CIBOO is normally copied to a disk using EXCHANGE, edited to contain the 
correct values in R2 and R3, and then copied back to the console as 
DEFBOO.CMD. 

• R3 needs to be further modified if volume shadowing is used. 

• R5 is used for software control to: 

Boot conversationally, into the Diagnostic Supervisor, or into VMS: 



R5 = 00004000 
R5 = 00004001 
R5 = 00004010 



boot to VMS 

conversational boot 

boot into Diagnostic Supervisor 



Boot into root directory other than 0: 

R5 = 10004000 ; boot from SYS1 
R5 = 50004000 ; boot from SYS5 

• CIBOO.CMD is normally modified under EXCHANGE and renamed 

CIGEN.CMD (conversational boot) or SCIBOO.CMD (Diagnostic Supervisor 
boot). 'tort 

\i 



t> £3 <Z 06C cool 
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Sample CIGEN.CMD 

• ExampleCIGEN.CMD: 



CIGEN.CMD 




I PORT CONVERSATIONAL BOOT 
COMMANO FILE - CIGEN 
BOOT FROM CI 

OESIREO STATION ADORESS OF REMOTE 
PORT IS SET IN REGISTER 2 ANO THE 
OESIRED UNIT NUMBER IS SET IN REGISTER 
3 BEFORE EXECUTING THIS COMMAND FILE 



^7 



HALT 

UNJAM 

INIT 

DEPOSIT/I 11 20003800 

DEPOSIT RO 20 

DEPOSIT R1JL„ 

DEPOSIT R4 ^ 

DEPOSIT R5 4001 

OEPOSIT FP 

START 20003000 

WAIT OONE 



HALT PROCESSOR 

UNJAM SB I 

INIT PROCESSOR 

SET UP SCBB 

CI PORT OEVICE 

CI TR»E 

BOOT BLOCK LBN (UNUSED) 

SOFTWARE BOOT FLAGS 

SET NO MACHINE CHK EXPECT 

START ROM PROGRAM 

WAIT FOR COMPLETION 



EXAMINE SP 

LOAD VM8.EXE/START;9 

START 9 



! SHOW ADDR OF WORKING MEM+'X200 
! LOAD PRIMARY BOOTSTRAP 
! START IT 
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Sample DEFBOO.CMD 

• The following is an example of booting a VAX- 11/750 from a disk attached to 
anHSC. 

• Note that it is really an edited version ofCIBOO.CMD. 



CI PORT BOOT COMMAND FILE 
BOOT FROM CI 



CIB00.CM0 



THE DESIRED STATION ADORESS REMOTE 
PORT IS SET IN REGISTER 2 AND THE 
DESIRED UNIT NUMBER IS SET IN REGISTER 
3 BEFORE EXECUTING THIS COMMAND FILE. 



D/G 20 


CI PORT DEVICE 


D/G 1 F3E000 


CI TR=E 


D/G 2 0100 


HSC 1 OR 


D/G 3 


DISK UNIT 


D/G 4 


BOOT BLOCK LBN (UNUSED) 


D/G 5 10000000 


SOFTWARE BOOT FLAGS SYS 1 


D/G E 200 


ADDRESS 'OF WORKING MEMORY 


LOAD VMB. EXE/START: 200 






LOAD PRIMARY BOOTSTRAP 


START 200 


START IT 



*20O 
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Node Shutdown in a Cluster 5 ^ r uorEs 

• Shutting down a system removes votes from the cluster quorum. 

• If the total number of votes drops below the cluster quorum, the remaining 
nodes will hang. 

• During normal shut down of a node (SYS$SYSTEM:SHUTDOWN), the 
shutdown procedure has the following options: 

REMOVE NODE: Removes node and recomputes the quorum value for the 

cluster using the votes available from all the nodes in the cluster including 
the node performing the shutdown. 

q 1AJ ^ <- CLUSTER_SHUTDOWN: All nodes will suspend activity and shut down 
^ AC fr ^ ^^Jtogether, after this option has been specified on each node. 

• If nodes crash or are removed from the system for an extended period of time, 
it may be necessary to lower the quorum in the remaining nodes: 

$ set cluster/quorum = n (new value for quorum) 

$ set cluster quorum (nodes compute new quorum) 

• The SET TIME command only affects the node on which it is entered (possible 
to have different times on different nodes). 



Mo5T 
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Device Naming in a VAXcluster 

Lesson Introduction 

This module discusses naming conventions in a VAXcluster. The name for a device 
in a cluster can be derived from either the node it is directly connected to or the 
Allocation Class of that node, if one is used. 

Lesson Objectives 

1. Describe the use of Allocation Class. 

2. List the steps required to serve a dual-ported disk to the cluster. 

3. Describe the installation and use of volume shadowing. 

4. Explain how to find information concerning mount disk volumes in a 
VAXcluster. 

Lesson Outline 

I. Introduction 

EL. Dual-Pathed Devices 

HI. Local Disks 

IV. Volume Shadowing 

V. Status 



TT 
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Disk and Tape Device Names 

• Disk or tape device names are of the form < node > $ < device > , where: 

- Node is the name of the node (HSC or VAX running MSCP server) to which 
the device is connected. . s 

- Device is the physical device name. •£ t*$tt* fP / 



• For example, a disk named HSC004$DUA1: is connected to HSC004 and is an 
RA81. 

-+- \ A device that is conncLtcd locally (no t served to Llni " clm > lcr) w4 U-no£~be 
■p reced e d b v the aude name , ^ c l " TfL ^ iz - 
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Dual-Pathed Device Names 

• A dual-ported device is accessible through more than one path. 

• Names of devices must reflect physical access paths. 

• The name of a dual-ported device is based on an allocation class assigned to 
each node connected to that device: 

- Allocation class is used to form a single name for a dual-ported device. 

- Allocation class is a number (0 to 255) given to a VAX by SYSGEN 
parameter ALLOCLASS, or SET ALLOCATE DISK on an HSC. 

- The allocation class number must be both non-zero and identical on both 
sides of the dual-ported device. 

• Result is a device name of $ < class > $ < device > , where: 

- Class is a number between 1 and 255. 

- Device is the physical drive. 

• For example, $l$dra3: would be an RM05 drive connected between two nodes 
with allocation class 1. 
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Local Disks in a Cluster 



• Local disks are not automatically cluster accessible. 

1 1 a • The MSCP server must be called up and then the device "served" to the 
fD^y^? cluster. 

- The following commands load the MSCP server: 




S RUN SYSSSYSTEMrSYSGEN 
MSCP 
EXIT 



- The following command will make a disk available cluster- wide: 



S SET DEVICE/SERVED LARRYS0RA4: 




• If the disk is going to be dual- ported, this must be specified before the disk is 
mounted by the following DCL command: 



$ SET OEVICE/DUAL PORT $2$DRA0: 



- A MASSBUS disk may be used as either a system disk or a dual-ported 
disk, but not both. 

- Note that the above command makes this disk available to all cluster 
nodes, not just the nodes physically connected to the disk. 




h 



U6 rLp_ load %*% *i>kk*tc tt smeb 

Us ^ 
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Mounting Disks in a Cluster 

• When mounting a disk, the following guidelines are useful: 
- On the system serving the disk, type: 



S MOUNT/CLUSTER <device-nama> 



- On a system not serving the device, type: 



$ MOUNT/SYSTEM <devico-name> 



• Sample commands for the disk configuration given on the following page: 



FOR SYSTEM MOE 

S SET HttQH 

$ RUN SYSSSYSTEM:SYGEN 

MSCP 

EXIT 
$ SET 0EVICE/DUAt_PORTED/SERVEO SlSOKAO 
$ SET OEVICE/SERVED MOESDMAO 
$ MOUMIZ£LUSJJE£/MQASiISJ MOESOMAO 

S MOHMT/rj ttSTER/NOASSIST $1$DRA0 

$ MniiHT/svsTFM/Mnft^JST DUDS0UA3 

$ MOUNT/SYSTEM/NOASSIST $255$0UA2 



PROO OISK 


WRKD1$ 


DOC OISK 


WRKD2S 


WRK3 


WRKD3S 


WRK4 


WRK04S 



FOR SYSTEM LARRY 

$ SET NOON 

$ RUN SYSSSYSTEM:SYSGEN 

MSCP 

EXIT 
S SET DEVICE/OUAL_PORTED/SERVED S1SORA0 
S MOUNT/CLUSTER/NOASSIST SlSORAO 
S MOUNT/SYSTEM/NOASSIST 0U0SDUA3 
S MOUNT/SYSTEM/NOASSIST $255$0UA2 



^ f 



LAMtf 



i 






I 



DOC_0ISK 

WRK3 

WRK4 



WRKD2S 
WRK03S 
WRKD4S 



FOR SYSTEM CURLEY 



S SET NOON 

$ MOUN T/SYSTEM /NOASSIST 0U0S0UA3 WRK3 

$ MOUNT/SYSTEM/NOASSIST 1Z55SD0A2 WRK4 



WRK03S 
WRK04S 
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DMAO 





VAX 
LARRY 
AC- 1 



VAX 
CURLY 




HSC 

MUM 

AC * 2551 




DUA3 



O 



DUA2 



AC - Allocation Class 
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Mounting Disks in a Command Procedure 

• The command procedure below will automatically mount all the disks shown 
in the preceding illustration. 

• In a command file, always use the qualifier /NO ASSIST with the MOUNT 
command. 

• The qualifier /NO REBUILD should be used if you are not mounting the disk 
for the first time (not done in this procedure). 

$ SET NOON - — ' 

$ ! Moe serves his local disks 

S IF FSGETSYI ("NOOENAME") .JHES . "MOE" THEN GOTO N0T_MOE 

$ RUN SYSSSYSTEM:SYSG£N 

MSCP 

EXIT 
S SET DEVICE/OUAL_PORTED/SERVED SISDRAO 
S SET DEVICE/SERVED MOESDMAO 

$ NOT_MOE : 4r- " 

S ! Larry serves his local disks 

S IF F$G£TSYI("NODENAME") v.NES. "LARRY" THEN GOTO NOTJ.ARRY 

$ RUN SYSSSYSTEM:SYSGEN 

MSCP 

EXIT 
S SET 0EVICE/DUAL_PORTED/SERVED SISDRAO 

$ NOTJ.ARRY : ^ _ 

S ! Moe mounts his local disks for the rest of the cluster 
$ IF FSGETSYI ("NOOENAME") .EQS. "MOE" THEN - 

MOUNT/CLUSTER/NOASSIST MOESDMAO PROOJ3ISK WRKD1S 
S ! Larry or Moe. but not both, mount the dual ported disk 
S ! for the rest of the cluster 

S IF FSGETSYI ("NOOENAME") .EQS. "CURLEY" THEN GOTO SKIP_NEXT' 
S MOUNT/CLUSTER/NOASSIST SISDRAO DOC_OISK WRKD2S 

S SKIP_NEXT: < 

S .'All nodes mount HSC disks 

S MOUNT/SYSTEM/NOASSIST DU0S0UA3 WRK3 WRKD3S 

$ MOUNT/SYSTEM/NOASSIST S255SDUA2 WRK4 WRK04S 
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Volume Shadowing 

• At host request, the HSC can "shadow" data by maintaining identical data on 
a set of disk drives during on-going I/O host operations. 

• Shadowing is a layered product used to ensure that critical data is not lost by 
duplicating this data on two or more compatible disk drives. 

• The HSC completely manages disk shadowing internally. 

• The host declares a set of disk drives as a shadow set, and then the drives are 
treated as one "virtual unit" distinct from any physical unit. 

• Any disk within a shadow set: 

- Must be identical in geometry. 

- Has to be mounted through the samejJpgSJttSlilflfe. 

bmt mo^t &e <?aj seef»z#rE *etv £sr nG ^ 

• The quorum disk cannot be shadowed. P ^ ^'^o 



I 



\)C 









y\A 



G o 
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Volume Shadowing (Cont.) 

• Install key (use release notes with key) 



$ 8SYSSUPDATE:VMSINSTAL 

Enable shadowing in SYSGEN 

$ MCR SYSGEN 
SYSGEN> SET VMS7 1 
SYSGEN> EXIT 
$ 



V5" 
"<mbo<xi '*!&- o, J 



err oft 



• Mount the members of the shadow set: uj h^ct\ 1^ vU -' 

$ MOUNT/SYSTEM $1$0US 12: /SHADOW* ($t$0UA2.$l$DUA3) USEROISK USERSDISK 

• If the disk to be shadowed is a system boot device, you must also do the 
following: 

- After installing key, copy VMB.EXE from SYS$SYSTEM to CSA1: using 

exchange: V — ^ To G-ZT fo£'^ ^KelzToa) bnveL 



% EXCHANGE COPY SYS$SYSTEM:VMB.EXE CSA1: 



- Modify R3 in DEFBOO.COM to reflect a shadow set: 

"""J^- ^iti-WME our /z lA > U/wr # 






OEPOSIT R3 800C0001 



u, 



Physical Drive Number 

^* Virtual Shadow Disk Number 

_^Informs VMB.EXE the system disk is a member of a 
shadow set 



Modify SYS$MANAGER:SYST ARTUP.COM to mount additional 
members of the shadow set. 



$ MOUNT/SYSTEM S1S0US12 :/SHA0OW«($l$0UAl : .S1S0UA0) VAXVMSRL4 
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Obtaining Status on Disks 

• The following printout is the result of typing the DCL command: 

$ SHOW DEVICE 

• The printout indicates: 

- Access path to a disk (dual- porting). 

- Number of nodes that have a disk mounted. 

- Disks mounted on another node. 

- Disks mounted on this node. 




Device 




Device 


Error 


Volume 


Free 


Trans 


Mnt 


Name 




Status 


Count 


Label 


Blocks 


Count 


Cnt 


S1SDHA1: 


(MOTHER) 


Mounted alloc 





(remote mnt) 


10342 





1 


S1S0MA2: 


(MOTHER) 


Onl ine 













S255XDJA4 


(MUM) 


Onl ine 













S255SDUA0 


(DUD) 


Mounted 





CLUSTERV4 


89752 


107 


2 


S255SDUA1 


(DUO) 


Onl ine 













4255S0UA2 


(MUM) 


Mounted 





WORK1 


166041 


11 


2 







<o if' 
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Obtaining Status on Local Disks 

• The following printout is the result of typing the DCL command: 

$ SHOW DEVICE/ FULL S1S0BA1: 

• The printout indicates: 

as The device and its characteristics. 
§ The device is served to cluster. 
- Where the device is mounted. 

Disk SlSOBAl: (STAR), device type RP06, is online, mounted, file-oriented 
device, shareable, served to cluster via MSCP Server, error logging is 
enabled. 



Error count 





Owner process 


n it 


Owner process ID 


00000000 


Reference count 


111 


Total blocks 


340670 


Total cylinders 


815 


Allocation class 


I 


Volume label " 


STARSS21AUG" 


duster size 


1 


Free blocks 


186870 


Extend quantity 


5 


Mount status 


System 


Extent cache size 


64 


File ID cache size 


64 


Quota cache size 






Operations completed 23129 

Owner UIC [1.1] 

Dev Prot S:RWED.O:RWED,G:RWED,W:RWED 
Default buffer size 512 

Sectors per track 22 

Tracks per cylinder 19 



Relative volume number 

~~) Transaction count 93 

Maximum files allowed 85167 

Mount count 6 
Cache name "_$1S0BAI:XQPCACHE" 

Maximum blocks in extent cache 18687 

Blocks currently in extent cache 16496 

Maximum buffers in FCP cache 346 



Volume status: subject to mount verfication, file high-water 

marketing, write-through caching enabled. 
Volume is also mounted on METERO, HELOS, GALAXY. DELPHI, CYPRUS. 

JHfO HA? *)cTifri& TO bo co/7// VfACLi'ST&e/ 

it screes ro *- of blocks ctosTeneb roQ^r/te/^ 

Fop P/lcS" ON t?tSK ■ 
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Obtaining Status on HSC Disks 

• The following printout is the result of typing the DCL command: 

S SHOW OEVICE/FULL S255$DUAO: 

• The printout indicates: 

- Type of device. 

- Host name. 

- Host type. 

- The name of other systems that have the disk mounted. 






^Ho^ 



^ 



Disk S255SOUA0: (MUM), device type RA81, is online, mounted, 
error logging enabled. 



Error count 
Owner process 
Owner process ID 
\ Reference count 



&^ flHost name 



ternate host name 
ocation class 



00000000 

121 

"MUM" 

"DUO" 

255 



Operations completed 29280 

Owner UIC [1.1] 

Dev Prot S:RWED,0:RwED.G:RWED,W:RWED 
Default buffer size 512 

Host type, available HS50, yes 
Alternate host type, avail HS50, yes 



Volume label "CLUSTERV4" 

Cluster size 1 

Free blocks 289699 

Extend quantity 5 

Mount status System 

File ID cache size 64 

Quota cache size 

Write-thru caching enabled 



Relative volume no. 
Transaction count 
Maximum files allowed 
Mount count 
Cache name 
Extent cache size 





116 

222768 

2 

'$255SDUA0:XQPCACHE- 

64 



Volume 1s subject to mount verification, file high-water marking. 
Volume is also mounted on SUPER. 
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System Directory Structure 

Lesson Introduction 

This module discusses the directory structure on the VAXcluster system disk. Each 
VAX has its own system root. There is also a common system root shared by all 
systems booting from this disk. 

Lesson Objectives 

1. Describe the use of the common system root and specific system roots. 

2. Identify system logical names. 

3. Define the use of search lists. 

4. Find the location of diagnostics on a cluster system disk. 
Lesson Outline 

I. System Roots 

II. Logical Names 

m. Field Service Directory 
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Managing the Field Service Account 

Knowledge of the directory structure is important when locating diagnostics: 

• Decide how many copies of the diagnostics you want in the cluster. 

• Decide if they should be located on a shared system disk or on a single disk 
that is available to the cluster but contains only diagnostics. 

• Use of the SET LOAD command may be required to locate the diagnostics. 
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System Directory Structure in a Cluster 

• An individual system disk has one system root (SYSO) containing all system 
files. 

• A shared system disk has: 

- Multiple system roots (SYS0,SYSl,SYS2...SYSD). 

- Each root directory contains the normal system directories (SYSEXE, 
SYSMAINT, etc.) and a directory called SYSCOMMON. 

- A new directory V4COMMON also contains normal system directories 
(SYSEXE, SYSMGR, SYSMAINT, etc). 

- SYSCOMMON is a synonym directory to V4COMMON. 

• All files in V4COMMON are the same files that are contained in the 
SYSCOMMON directory of each root. 

• Since V4COMMON and SYSCOMMON directories are synonymous, deleting 
a file from one directory causes it to be deleted from all the directories. 

• Each node, and only one node, boots from a top-level root directory (SYSn). 

• Each root is created during a VMS installation by executing a command file 
MAKEROOT.COM. 
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Directory Structure of a Share cUSy stem Disk 



000000 




SYSO 
-SYSCBI 
-SYSERR 
-SYSEXE 
-SYSHLP 
-SYSLIB 
-SYSMAINT 
-SYSMGR 
-SYSMSG 
-SYSTEST 
-SYSUPD 
-SYSCOMMON 

t 



SYS1 

-SYSCBI 
-SYSERR 
-SYSEXE 

SYSHLP 
-SYSLIB 
-SYSMAINT 

SYSMGR 
h SYSMSG 
'SYSTEST 
-SYSUPD 
-SYSCOMMON 

4 



V5 



-SYSERR 
-SYSEXE 
-SYSHLP 
-SYSLIB 
-SYSMAINT **■ 

SYSMGR 

SYSMSG 
-SYSTEST 
-SYSUPD 



SYSCOMMON . 
SYSMAINT and 
V4C0MM0N. SYSMAINT 
are synonym 
directories 



SYSCOMMON and V4C0MM0N 
are synonym directories 



MKV84-2869 
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Logical Names and the Common System Disk Directory 
Structure 

• In an environment of clustered CPUs, logical names must support the 
different directory structure of a common system disk. 

• Logical names are created using the standard DCL ASSIGN and DEFINE 
commands. 

• Record Management Services (RMS) use logical names to implement search 
lists that look in more than one place for a file. 

• When searching for a file, the first translation is used, then the second, then 
the third, until the file is finally located. 

• The user controls the order of searching by using the DE FINE and ASSIGN 
commands to specify multiple translations of a single logical name. 

• The logical name SYS$SPECIFIC points to the node-specific root: 

"SYSSSPECIFIC- » -HSCOOaSOUAliCSYSl.]" 

• The logical name SYS$COMMON points to the common directory tree: 

"SYSJCOMMON" * "HSC003$OUA1:[SYS1.SYSCOMMON.]" 



\h& & * 
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Logical Names and the Common System Disk Directory 
Structure (Cont.) 

• Some logical names point to two directories: 

"SYSSSYSTEM" » "SYSSSYSROOT: [SYSEXE]" which translates to both: 

"SYSSSYSDEVICE : [SYSO . SYSEXE] 
"SYSSSYSDEVICE : [SYSO . SYSCOMMON . SYSEXE ] " 

• When VMS searches for a file, a search list is used to first look in the node- 
specific root and then in the common root: 

"SYSSSYSROOT" = "SlSDUAO :[SYS3. ]" (LNM$SYSTEM_TABLE) 

» "SYSSCOMMON:" 
"SYSSCOMMON" = "SlSDUAO :[SYS3. SYSCOMMON.]" (LNM$SYSTEM_TABLE) 

• To refer to a single directory, use SYS$SPECIFIC or SYS$COMMON rather 
thanSYS$SYSROOT. 

• Some logical names related to the directory structure: 

"SYSSUBRARY" = "255SDUA0 : [SYSO. SYSCOMMON. ]" 
"SYSSMANAGER" ■ "SYSSSYSROOT :[SYSMGR] " 
"SYSSNOOE" = "HARPO::" 
"SYSSLOGIN" * "SYSSSYSTEM:SYLOGIN" 
-SYSSSYSDEVICE" « "S255$OUA0:[SYS0 . ]" 

* "SYSSCOMMON:" 
"SYSSSYSTEM" * "SYSSSYSROOT: [SYSEXE]" 
"SYSUAF" * "SYSSCOMMON: [SYSEXE ]SYSUAF. OAT" 
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Obtaining a Directory Listing 



$ OIR SYSSSYSTEM 

Olroctory SYSSSYSROOT: [SYSEXE] 



ACMSAAF.DAT; 1 
DBMMON.LOG; 162 
SETPARAMS.DAT; 3 
SYSUAF.LIS;! 



ACMSAAU.LIS;3 
DBMMON.LOG: 161 
SORTED.0AT;2 
TEST.0UT;3 



Total of 12 files. 

Directory SYSSCOMMON: [SYSEXE] 



2020V111.EXE;1 
ACC.£XE;1 
MSACC.EXE; 4 
YEDRIVER.EXE; 1 
YEDRIVER.EXE: 1 
YEDRIVER.EXE;! 



A.MAR:1 
ACLEDT.EXE; 1 
ACMSADU.EXE; 4 
YFDRIVER.EXE; 1 
YFORIVER.EXE: 1 
YFDRIVER.EXE;! 



[note 1] 

ACMSPAR.ACM;9 
JBCSYSQUE.DAT; 1 
SWAPFIIE.SYS;1 
VAXVMSSYS.OLD;! 



[note 2] 

AA.;1 

ACMS.MOB;4 
ACMSATLOG . EXE ; 4 
YIDRIVER.EXE.-l 
YIDRIVER.EXE; 1 
YIDRIVER.EXE;! 



Total of 18 files. 

Grand total of 2 directories, 30 files. 

Note 1 = Files from the system specific root. 
Note 2 = Files from the common root. 
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Obtaining a Directory Listing (Cont.) 



S OIR SYSSMAINTENANCE 

Oi rectory SYSSSYSROOT: [SYSMAINT] 

C0NFIG.COM; 1 
0UCT_0IAG_UNSRT . TMP ; 2 
SHOW. LIS ;1 



[note I] 

OUCT_CURR_ACCT . TMP ; 1 
DUCT 0UCT.COM; 2 



Total of 5 files. 



Oi rectory SYSSCOMMON: [SYSMAINT] 

.;1 CI780.8IN:1 

CI780_V70.BIN; 1 

DIAG.C0M;9 

0R750.0AT;1 

DUCT. EXE; 2 

EBSAA.EXE; 635 

ECKAM.HLP;5 

ED0AA2.HLP;6 

EDSAA.EXE; 239 

ESCCA.EXE; 1 

EVAAA.HLP;6 

EVCKF.HLP;15 

KA0021.PAT;1 

KAINIT2.SYS;1 

MCCK01.COF_8600;i 

RELEASEJIOTES.DOC: 1 

U0KX.BPN;4 

YPL0A0.COM;! 



[note 2] 

CI780_V50.BIN;! 

CONSOL.SYS;30 CS800KA.SYS;2 

0IAG2.COM; 30IAG800T.EXE; 2 

DR780.DAT; 1 OUBOOKA. SYS ;1 

EBDAN.EXE; 67 EBOAN.HLP;10 

EBUCA.COM; 2 EBUCA.EXE; 2 

ECKAX . EXE ; 4 ECKAX . HLP ; 3 

ED0AA3.HLP;4 ED0AA4.HLP;4 

EEK6M.BPN;1EEK7M.BPN:1 

ESCCB.EXE; 1ESCCB. HLP: 2 

EVAAB.EXE; 1 EVAAB. HLP ;1 

EV0AA.EXE; I EVOAA. HLP ;1 

KA8B00.SYS;1 KA8B002.SYS; 1 

KKTMA0.PAK;1 L0A0GS.COM; 1 

MC0004.CDF_8500;1 MCF.BPN_860Q; 1 

RL02.COM_8600;23 RL02BUILD.CSH_8600;5 

U0KY.BPN;4 UEKM.BPN;3 

YOORIVER.EXE; 9 Y0L0A0.COM;! 



Total of 54 files. 

Grand total of 2 directories, 59 files. 

Note 1 = Files from the system specific root. 
Note 2 = Files from the common root. 
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VMS Build in a Cluster 

Lesson Introduction 

This module discusses installing VMS on a Cluster Common System Disk. It also 
discusses how to access and modify the S YSGEN parameters that affect the VAX as 
a node in a cluster, placement of system files, and configuration suggestions. 

Installing VMS in a cluster environment is more complicated than a single system 
installation. Manual modification of SYSGEN parameters is required after the ~L \/ Li £_ 
initial installation, as well as adding additional system roots. J JjfOL^i 

There are two different groups of parameters known as SCS and cluster. SCS 
parameters deal more with the actual Cl-to-CI communications while the cluster 
parameters define items for the SYSAPs. 

In large clusters, there may be a nned to modify the placement of certain files in 
order to make disk I/O more efficient. 

Lesson Objectives 

1. Describe how VMS is installed. 

2. Describe additional system roots. 

3. Describe the setting of particular SYSGEN parameters. 

4. List and describe the placement of Startup Command procedures. 

5. List and describe the placement of User Environment files. 

6. List and describe the placement of system files. 

7. List and define any configuration restrictions for building and maintaining a 
VAXcluster. 
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Lesson 


Outline 


I. 


Installing VMS 


n. 


Adding Roots 


m. 


AUTOGEN 


IV. 


Access 


v. 


Cluster 


VI. 


SCS 


vn. 


HSC Similarities 


vm. 


Command Procedures 


IX. 


Environment Files 


X. 


System Files 


XI. 


Performance Considerations 


xn. 


Disk Configuration 


xm. 


Revision Control 
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Building VMS on the First Node 

• The following steps outline how to build VMS for a shared system disk. 

• Basically, the first build is used to create all the roots for the other nodes; then 
each additional node is booted to a different root after changing each 
SCSSYSTEMID and SCSNODE parameter. 

Step 1. Install VMS from the standard distribution kit. 

Step 2. Answer "yes" to the question "Do you want to generate a cluster 
common disk?" and enter the SCSSYTEMID and SCSNODE 
parameters for the node you are on. 

Step 3. After the system shuts down, do a conversational boot (depositing 
the appropriate value in R2, R3, and R5). 

Step 4. Edit MODPARAMS.D AT to see if the appropriate values of 
SCSNODE and SCSSYSTEMID are there. 

Step 5. AUTOGEN the system. 

Step 6. After the system shuts down again, reboot. 

Step 7. Set your default at SYS$MANAGER and run MAKEROOT.COM ^ y/£i 

for each additional CPU (node) in the cluster. ^ *£. 

CU) ST~£^ - Co a; Fi£ 

Step 8. MAKER00T.COM will prompt you for the root name (SYSn), the 
SCS node name, and the SCS system ID. 

Step 9. Shut down VMS. 
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Building VMS on Additional Nodes 

• This is a continuation of outlining a VMS build on a common system disk 
(previous page). 

• At this point, the first system boots to the S YSO directory of a common system 
disk and you have built roots for all the other nodes in your cluster on the 
same disk. 

• Also, you have edited CIBOO.CMD for the first system and copied it back onto 
the console device as DEFBOO.CMD. 

• For each additional node in the cluster, perform the following steps. 

Step 1. Perform a conversational boot (remember to change the contents of 
R5 to reflect the different root through which you are booting). 

Step 2. Edit MODPARAMS.DAT to reflect the new values of 
SCSSYSTEMID, SCSNODE parameters. 

Step 3. AUTOGEN the system. 

Step 4. Shutdown VMS. 

Step 5. Go to the next node and repeat Steps 1 through 4. 
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Using AUTOGEN 

• AUTOGEN is used to change cluster SYSGEN parameters (such as SCS node 
name and SCS system id) rather than making the changes under SYSGEN 
because: 

- You have a record of changes in MODPARAMS.DAT. 

- AUTOGEN reconfigures other parameters to reflect your changes. 

- Changes recorded in MODPARAMS are not lost during VMS updates. 

• To modify SYSGEN parameters: 

- Edit SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT. 

- Execute SYS$UPDATE:AUTOGEN.COM. 

• SampleofMODPARAMS.DAT: 



S SET OEF SYS$SYSPECIFIC:[SYSEXE] 
S EDIT MO0PARAMS.DAT 



Site specific AUTOGEN data file. In a VAXcluster where 
a common system disk is being used, this file should 
reside in 5Y5SSPECIFIC:[SYSEXE], not a common system 
directory. 

Add modification that you wish to make to AUTOGEN's 
hardware configuration data, system parameter calculations 
and page, swap, and dump file sizes: 

SCSSYSTEMID«1060 'System 10 for the CI 
SCSNODE="ALFALF" ISystem node name for CI 

•EXIT 

S 9SYSJUP0ATE: AUTOGEN SAVPARAMS REBOOT 
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VAXcluster SYSGEN Parameters 

• For systems to boot properly into a VAXcluster, certain system parameters 
must be set on each cluster node using SYSGEN. 

• There are two categories of SYSGEN parameters: 

- Cluster parameters. 

- SCS parameters. 

• Cluster parameters affect the Connection Manager operation, the important 
1 ones being: ^ ^/-^^ TcifJ ugjA f . 






V A* CLUSTER ^ 0/»/^> 

QUORUM - tct^u clvs vcr^^^/z 

DISK__QUORUM 

QDSiVOTES — & i/cfef Fee, Qwtu'M biSK 

ALLOCLASS 

VOTES 

• SCS parameters of importance are: ^* zaama ^ v^ \^ L ^ 

SCSSYSTEMID ~ r ^ roKm ^ 

SCSSYSTEMIDH 

SCSNODE 

• SYSGEN can be entered on a conversational boot and VOTES changed before 
the node comes up into VMS. f(LQt\ 5^5B#eT^ 

• Equivalent parameters in an HSC changed using the SETSHO utility are: 

SET ED <^ F a 

SET ALLOCATE D\5K<r- fiiiOCUA65 
SET NAME 
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Location of Command Procedures 



/A) SVS/y>/\A)4&£g 



• In a cluster environment, the location of the following command procedures is 
important: 



SYCONFIG.COM 
V4 -^ SYSTARTUP.COM 

SYSTARTUP G0MM0N.COM 



SYSL0GIN.COM 



Loads and configures node-specific 
drivers. 

Installs images, defines logicals, mounts 
disks, starts job controller,and sets-up 
terminal lines for specific nodes. 

Located on the system common disk; 
contains conditional code for node 
specific tasks (disk, mounts, queue 
control). 

Defines symbols that will work 
throughout the cluster. 



• Regardless of which command procedure is used during system startup, the 
rule to remember is this: 

- If a command procedure is in SYS$COMMON, it must be able to run on 
any node, 

OR 

- If a commmand procedure is node-specific, it should not be placed in the 
SYSCOMMON directory, but in the SYS$SPECIFIC directory. 
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Location of System Files 



• The following system files are important because they define the user 
environment on all nodes: 



SYSUAF.DAT 



NETUAF.DAT 



VMSMAIL.DAT 



RIGHTSLIST.DAT fc a &c&* 
JBCSYSQUE.DAT 



Contains login information such as 
username, password, default directory, 
quotas, and privileges. 

Contains proxy information that 
indicates which remote node/user 
combinations are allowed to bypass 
network access control checks. 

Contains mail information such as 
forwarding address and persons name. 

Contains information about what the 
user is allowed to access. 

Contains information about the various 
queues in the cluster. 



• These files are "high-usage" — constant access to them involves a lot of I/O 
activity. 

• The general rule is to take these files off the common system disk and put 
them onto a non-shared disk. 
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Location of Page and Swap Files 

• The page and swap files are used by memory management: 

SWAPFILE.SYS Provides temporary disk storage for 

processes forced out of memory by a 
memory management operation. 

PAGEFTLE.SYS Provides temporary disk storage for 

pages forced out of memory by a memory 
management operation. 

• Both swap and page files are used to save the working sets of processes that 
are not in the balance set. 

• These files are also considered "high-usage." A lot of I/O activity is centered 
around them. 

• Generally, the files PAGEFILE.SYS and SWAPFILE.SYS are moved to a disk 
other than the shared system disk. 



6 r/^^ 
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Performance Considerations 

• Disks are the primary performance bottleneck in a cluster because multiple 

nodes (CPUs) can make I/O requests to the same disk. /< v * Mixeb cuv^eZ 
/V/OcTtte^ 6oiTL£A}&ciC i$ the bevvA 

• The more users who share a resource (such as a file), the more synchronization 
is needed. 

- A locking operation that requires communication between nodes takes two 
to nine times longer than a locking operation within one node. 

- If users on different nodes share files, it can take longer to lock files than if 
all users were on one node. 

• Cluster-related software overhead (Lock Manager, Connection Manager, etc) 
requires more memory as more nodes are added. 

- Any VAXcluster requires a minimum of 4 Mb of memory on each node . 

- For each node added, an addition of 1/2 Mb of memory on all nodes is 
recommended. 

• Synchronization (Lock Manager) overhead is only a fraction of total CPU time 
taken for an I/O operation — the VAXcluster usually becomes I/O bound before 
locking overhead becomes significant. 
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Disk Configurations 

• Since a VAXcIuster performance is affected most by I/O operations, the 
following guidelines for disks are useful. 

• Multiple systems can share a common system disk, but the following issues 
should be considered: 



- A single common disk represents a single point of failure. jjAJutSS ^ $~#A1>ck'' 



A)Cr /S t»«£5-- 





- Use of multiple common disks. CH^uV \f S H^t>e[^W&' 

A>cT 05£t> 

a. Example 1 



Five VAX systems (quorum is three) — since the cluster can function 
with a loss of up to two systems, configure it with three or more system 
disks, each dual-ported between two HSCs: 

C 15 
disk 1 for two systems ^<r~ U ! ^> 

disk 2 for two systems 

disk 3 for one system 






b. Example 2 
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Ten VAX systems (quorum is six) — since the cluster can function with 
a loss of up to four systems, configure it with three or more system 
disks: 

disk 1 for four systems 
disk 2 for three systems 
disk 3 for three systems 

Disk I/O performance has the following characteristics: 

- Most disks are specified for 30 to 35 1/Os per second. 

- Peak loads often triple average load. 

- Average load per spindle over 30 minutes should not exceed 10 to 15 I/Os 
per second. U^£ AAOti ITO fc b}*$K 

- Move as much activity away from system disk as possible. 
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Disk Configurations (Cont.) 

• A dual-ported MASSBUS disk cannot be used as a system disk. 

• An RA disk can be dual-ported between an HSC and a VAX node or between 
two VAX nodes, but: 



-£=> 




- Automatic failover is not supported. 

- For proper failover, disk must be dismounted, port select switch from other 
port must be enabled, and then the disk remounted. 






5Ha. /i)or &&n*>6£fi rfsc-"t VAX 
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Revision Control 

• VAXcIusters are created from many different hardware and software 
components. 

• Revision control is important throughout the cluster — a single component 
that is not at the correct revision level may create problems for the entire 
cluster. 

• Some of the important elements include: 

- CI Port revisions (hardware and microcode). 

- CPU revisions (hardware and microcode). 

- Console floppy revisions (VMB, CI780.BIN). 

- HSC revisions (hardware and software). — ^ H0W *&*»&&*** 

- VMS version. 

- Diagnostic version. 

• Most revision control information is available in the pink fiche. 

fcvb Reus 

t/01 ttsc 
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Maintenance Tools 
Lesson Introduction 

This module discusses utilities that aid in troubleshooting cluster problems. Two of 
the tools discussed, VAXsim and DECnet, require a license. 

DECnet is useful in a cluster because of its ability to add communication power 
between nodes. DECnet is not required but is strongly recommended. From a 
troubleshooting point-of-view, DECnet is only used indirectly, however its absence 
becomes extremely obvious while using other tools. 

Lesson Objectives 

1. Describe the use of VAXsim, SHOW CLUSTER, MONITOR, and 
ANALYZE/ERROR_LOG. 

2. Explain how and why DECnet is used for troubleshooting. 

3. Identify problems in a cluster using the aforementioned tools. 

Lesson Outline 

I. DECnet 

H. VAXsim 

m. ANALYZE/ERROR_LOG 

IV. Monitor 

V. Show Cluster 
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VAXsim (VAX System Integrity Monitor) 

• VAXsim is a layered product. 

• Provides a graphic display of hardware status within one node or across 
complete cluster. 

• Monitors errors as they are logged. 

• Performs cursory analysis rather than in-depth analysis. 

• Does not replace ANALYZE/ERROR_LOG utility. 

• Provides quick indication of which option is failing, not necessarily an 
indication of what caused the problem. 
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VAXsim Data Collection 

• VAXsim Mailbox contains a current error log record (identical to what is in 
ERRLOG.SYS). 

• VAXsim Monitor is a detached process that: 

- Attaches itself to the Mailbox. 

- Reads each Mailbox entry. 

- Filters out extraneous error log information. 

- Creates and maintains its own historical database in VAXsimDAT.DAT. 

• VAXsim.EXE allows viewing of the database file. 

- Creates and maintains a display database in memory from single or 
multiple VAXsimDAT.DAT files. 

- Displays error rates and error logs. 

- Provides several display levels. 
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VAXsim Overview 
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VAXsim MONITOR 
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Analyze Utility 

• ANALYZE/ERROR__LOG formats the error log entries (from ERRLOG.SYS 
file) into a readable format. 

• Command options are used to narrow down the error log output to: 

- A specific device. 

- A specific time. 

- A particular form. 

• To obtain output related only to a specific device, use the /INCLUDE option: 

S ANAL/ERR/ INCLUDE =0UA1: 

• To obtain output of only a particular type of error, use the /INCLUDE and 
/EXCLUDE options: 

S ANAL/ERR/ INCLUDE »DUA I : /EXCLUDE >VOLUME_CHANGES 

• To obtain output relating to a particular time use the /SINCE and /BEFORE 
options: 

$ ANAL/ERR/INCLU0E»PAA0/SINCE = U-JAN-1988/BEFORE»14-JAN-1988 

• Use the /SUMMARY = HISTORGRAM option for a quick view of the number 
of errors and the time of occurrence: 

S ANAL/ERR/INCLU0E=PAAC/5UM=HIST/N0FULL 
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Monitor Cluster Utility 

• Gathers data for up to sixteen nodes in a cluster. 

• Data items examined include: J- 

- Percent of CPU in use. j> (V ,fQ 

- Percent of memory in use. / v A \/ . 

- I/O operation rate. \J IAk 

- Total ENQ/DEQ rate. 

• Especially useful for monitoring and recording total disk activity. 

• Format of the output can be "tabular" or "bar-graph" 

• Uses DECnet to establish a monitor server process on each node from which it 
gathers data. 
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Show Cluster Utility 

• The SHOW CLUSTER command provides a view of the VAXcluster from a 
single node. 

• The SHOW CLUSTER command provides a view of the VAXcluster and then 
returns user to DCL prompt. 

• The SHOW CLUSTER/CONTINUOUS command displays data continuously 
and updates the display at specific intervals. 

• The /CONTINUOUS qualifier allows the user to enter a utility command that 
changes the contents of the display, allowing the user access to over 100 fields 
of data. 

• The SHOW CLUSTER report consists of three windows from which data is 
collected for all fields: 



SCS window 



CLUSTER window 



LOCAL PORTS window 



Contains data collected from the System 
Communications Services database (SCS). 

Contains data collected from the Connection 
Manager database. 

Contains data collected from the CI Port 
database. 
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DECnet in a VAXcluster 

• DECnet should be installed and running on every node in a VAXcluster. 

• No cluster component requires DECnet for communication, but DECnet 
provides many functions that can complement cluster operation and 
management: 

- Allows access to disks that are not available cluster- wide. 

- Allows logins on any cluster node from any terminal using the SET HOST 
command. 

- Allows distributed applications that require DECnet to work (VAXsim, 
MONITOR). 

- Allows VAXcluster nodes to be part of a larger network. 

• The DECnet class driver can operate over the CI Bus, but normally this is not 
done. 

- The Ethernet path yields faster throughput and less overhead. 

- DUP must use CI since Ethernet does not attach to the HSC. 

• DECnet account in UAF must match the DECnet account of NCP. 
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